1. Field of Invention
The invention relates generally to computer systems. More particularly, methods and apparatus for distributed testing of components in an enterprise computer system.
2. Description of Relevant Art
Enterprises today need to extend their reach, reduce their costs, and lower their response times by providing easy-to-access services to their customers, partners, employees, and suppliers. Typically, applications that provide these services must combine existing enterprise information systems (EIS) with new business functions that deliver services to a broad range of users. These services need to be highly available in order to meet the needs of today""s global business environment secure so as to protect the privacy of users and the integrity of enterprise data, as well as both reliable and scalable to insure that business transactions are accurately and promptly processed. For a variety of reasons, these services are generally configured as distributed applications consisting of several tiers, including clients on the front end, data resources on the back end, and one or more middle tiers between them where the majority of the application development work is done. The middle tier implements the new services that integrate existing EISs with the business functions and data of the new service. The middle tier shields the client tier from the complexity of the enterprise and takes advantage of rapidly maturing Internet technologies to minimize user administration and training.
One approach to constructing such an enterprise computing system is to use component based, multi-tier applications based on, for example, Java 2 Enterprise Edition (J2EE) technology from Sun Microsystems Inc. of Mountain View, Calif. As well known in the art, J2EE is a Java platform designed for the mainframe-scale computing typical of large enterprises representing a multi-tier design that simplifies developing, deploying, and maintaining enterprise applications. In this regard, J2EE has been designed to simplify application development in a thin client tier environment by simplifying application development and decreasing the need for programming and programmer training by creating standardized, reusable modular components and by enabling the tier to handle many aspects of programming automatically. It enables developers to focus on the specifics of programming their business logic, relying on the J2EE server to provide system services, and client-side applications (both stand alone and within web browsers) to provide the user interaction. Once developed, business logic can be deployed on servers appropriate to existing needs of an organization.
J2EE includes a number of components such as Enterprise JavaBeans (EJB) that is a server-based technology for the delivery of program components in an enterprise environment, Java servlet application program interfaces that enhances consistency for developers without requiring a graphical user interface, and Java Server Pages (that is the Java equivalent to Microsoft""s Active Server Pages) is used for dynamic Web-enabled data access and manipulation.
Compatibility is one of the keys to the success of the J2EE and one of the factors that make it so productive for IT organizations. With this in mind, J2EE platform vendors will need to verify that their implementations conform to the J2EE platform specification. Toward that end, what is referred to as a J2EE Compatibility Test Suite (CTS) has been developed by Sun Microsystems that ensures consistent implementation across various vendor offerings. For application developers, this means full portability for enterprise applications. The CTS includes tests for all classes and methods required by the J2EE specification as well as end-to-end tests to check that all layers of a J2EE application will interact correctly and consistently. In this way, the CTS helps ensure that Enterprise JavaBeans components, JavaServer Pages, and servlets that run on one vendor""s J2EE branded configuration will run on every J2EE branded configuration. In this way, the CTS assures enterprises and developers that APIs and development features are available in the branded implementation and work in a uniform way.
Many of the tests included in the CTS are not end to end tests in that the test must be run at several locations (i.e., containers) since the Java specification defines several locations from which some or all of the aforementioned APIs must be accessible which must be tested as part of the CTS. One such test is an API test that checks to make sure that a service API (such as, for example, JDBC, JTA, JavaMail, etc.) is implemented according to the Java specification. Unfortunately, however, as currently configured, a separate test must be written for each API in each J2EE container. By writing separate tests for every API in every container, a substantial amount of programming resources is wasted since substantially the same code is copied for every test so written.
Therefore, in view of the foregoing, it would be advantageous and therefore desirable to have the capability of performing a distributed test in an enterprise computing environment such that a programmer would only be required to know the API for which the test is designed and not its particular location.
Broadly speaking, the invention relates to an improved method, apparatus and computer system for performing a distributed test in an enterprise computing environment. In one embodiment, a method of automatically performing a component test at any number of locations in a distributed environment is disclosed. In general, in order to assure compatibility of the various components in an enterprise computing system, a service test is created as part of a compatibility test suite and passed to a test application server having a test application program. The test application program includes a plurality of vehicle classes each of which is used to implement each of the object types that are run in each of a plurality of containers, such as, for example, a JSP vehicle, a servlet vehicle, and an EJB vehicle. During the build process of the CTS, each service test is automatically packaged with each of the appropriate vehicle classes so that each can be deployed into and run within the associated container.